БЭМ

exessqd1 · October 19, 2011

Несмотря на то что концепция независимых блоков(БЭМ) существует уже около 3 лет, большинство верстальщиков очень смутно понимают что это такое.

Между тем множество крупных порталов используют этот метод в верстке, такие как yandex,rambler,yahoo(oocss - тот же bem, только попроще)...

Препятствует понимаю БЭМ и то, что статьи и видео по БЭМ методу разбросаны по сети, и очень сложно и долго самому их искать и выписывать, какая-то информация уже устарела.

Было решено сделать общий проект который объединит все знания из bem, oocss в понятной и доступной форме.

Добро пожаловать

Дополнительные материалы.

BEM клуб http://clubs.ya.ru/bem/

BEM видео

http://clubs.ya.ru/bem/replies.xml?item_no=1009

http://video.yandex.ru/users/ya-events/view/16/

http://video.yandex.ru/users/ya-events/view/14/

http://video.yandex.ru/users/ya-events/view/15/?cauthor=ya-events&cid=2

http://video.yandex.ru/users/ya-events/view/13/

http://clubs.ya.ru/bem/replies.xml?item_no=864

psywalker · October 19, 2011

exessqd1,

Дружище, так ты ответишь мне на вопрос или нет?

Зачем использовать в полной мере БЭМ на обычных сайтах? НЕ крупных порталах.

NeoMurderer · October 19, 2011

Как по мне - бред

psywalker · October 19, 2011

Как по мне - бред

Обоснуй пожалуйста.

NeoMurderer · October 19, 2011

Как по мне название класса

b-grid_menu_footer

слишком длинное и немного неудобно,префиксы тоже

Да и вообще это всё как и написано используется у больших проектах,а их единици и делают их не такие простые верстальщики как мы а профи.

psywalker · October 19, 2011

Как по мне название класса
b-grid_menu_footer
слишком длинное и немного неудобно,префиксы тоже

Ты не совсем понял смысл всего этого подхода. Название классов происходят и удлиняются не просто так. У них тоже есть своя закономерность. Да и префиксы - это не панацея, можно и без них вполне себе обойтись и так же при этом следую техники БЭМ. Тут речь о другом. Мне просто не понятен фанатизм топикстартера, и поэтому я хочу получить ответы на свои вопросы, чтобы возможно, стать мудрее в этих делах.

Да и вообще это всё как и написано используется у больших проектах,а их единици и делают их не такие простые верстальщики как мы а профи.

Вполне себе можно использовать БЭМ и на обычных хомяках, но опять же, отчасти, а не кидаться в омут с головой.

Veseloff · October 20, 2011

Было решено сделать общий проект который объединит все знания из bem, oocss в понятной и доступной форме.

А чего он состоит из одной страницы и такой длинный? Мне кажется, что при таком подходе не хватает в конце страницы отсканенного автографа и надписи типа «гарантирую вам, что вы станете мегакрутым верстальщиком, если будете использовать БЭМ».

ceil100 · October 20, 2011

каскадные таблицы на то и каскадные, чтобы использовать всю их силу

а множить количество классов до бесконечности, да еще давать им километровые названия это бред

это подход дилетанта, который не понимает вложенности, что куда определяется и как этим пользоваться

БЭМ это подход программиста, который не понимает и не хочет понять что такое CSS, зато он знает ООП и делает себе костыль из него,

а потом говорит, что без этого костыля ходить не возможно.

не знаю насколько большим должен быть проект, чтобы использовать БЭМ, но достаточно посмотреть на CSS БЭМ-сайта, чтобы понять, что это бред

то что можно вместить в тридцать строк при правильном коде там растянуто на триста с лишним, с классами по три километра длиной

с таким кодом нагрузка не только не уменьшится, она возрастет еще больше, а поддерживать такой код, это же с ума сойдешь когда сайт еще в пару раз увеличится

Edited October 20, 2011 by ceil100

Shift-Web · October 20, 2011

В шаблонизаторе BEMHTML есть возможность порождать новые блоки внутри шаблонов. Получается что-то вроде инклудов, только поумнее.

Походу автоматизируется. Если да, то менее бредово не стаёт, но часть гемороя пропадает

mishka · October 20, 2011

со временем я тоже стал думать о чем-то типа БЭМ. Даже на маленьких сайтах появилась привычка давать такие классы, с приставкой по их родителю. Если это логотип в хедере, то он у меня ".h-logo", или меню: ".h-nav", меню в сайдбаре ".s-nav". Я чувствовал необходимость такого подхода, но незнал как это сделать лучше. Когда узнал про БЭМ, мне эта идея очень понравилась. Насчет дилетанства в наименовании классов - бред. Такое мог сказать человек который только и делает маленькую страничку с css до 1000 строк, в таком формате:

div {
    width: 500px;
    margin: ...;
    padding: ...;
}

А когда с талкиваешся с тем что нужно проапдейтить проект, а в нем все сделанно полагаясь на каскадность, как говорит предыдущий автор и ты видишь такой код:

<form action="#">
    <fieldset>
        <div class="hold-text">
            <div><input type="text" /></div>
        </div>
    </fieldset>
</form>

.hold-text {
    width: ...;
    background: ...;
    .....
}
.hold-text div {
    padding: ...;
    background: ...;
    .....
}
.hold-text input {
    ...
}

И тут нужно рядом с инпутом всунуть еще блок с непростой структурой, у него внутри еще пара блоков будет то тогда приходится писать:

.hold-text .message {
    padding: auto;
    float: none;
    margin: auto;
    ....
}
.hold-text .message .m-frame {
    padding: auto;
    float: none;
    margin: auto;
    ....
}

Этот минимализм оправдан разве что в примерах, когда нужно кому-то показать как что работает, поэтому быстро набросал и показал. Но к сожалению многие это примут за чистую монету, и сами тоже начинают страдать минимализмом.

Вот пример спискозадротов:

<div class="gallery">
    <ul>
        <li><img src="" alt=""/></li>
        <li><img src="" alt=""/></li>
        <li><img src="" alt=""/></li>
    </ul>
    <ul class="switcher">
        <li><a href="#"></a></li>
        <li><a href="#"></a></li>
        <li><a href="#"></a></li>
    </ul>
</div>

.gallery ul {
    padding: 0;
    margin: 0;
    list-style: none;
    width: ;
    height: ;
    overflow: hidden;
    position: relative;
}
.gallery li { /* тут я немного сократил, обычно пишут .gallery ul li */
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
}
.gallery a { /* Это какая-то кнопочка в галлереи. тут я немного сократил, обычно пишут .gallery ul li a */
    position: absolute;
    top: 50px;
    left: 50px;
    width: 100px;
    height: 30px;
    background: url(image.png);
}
.gallery .switcher {
    width: auto;
    height: auto;
}
.gallery .switcher li {
    position: static;
    float: left;
}
.gallery .switcher a {
    position: static;
    width: ..;
    height: ..;
    background: ..;
}

А теперь представьте что в галлее не просто картинки будут, а там еще и описание полноценное появится, и внутрь ее придется всунуть простой маркированный список.

Это то с чем я часто сталкиваюсь.

А вот задай классы изначально элементам, да задай им стили через эти классы, а если еще и классы не от фанаря а логично будут проставлены(а в БЭМ так и есть), сделай лучше не себе в данный момент, а тем кто потом будет поддерживать твой код, возможно даже это ты будешь.

БЭМ - это не больная фантазия, это логичный результат многих часов работы.

Softlink · October 20, 2011

БЭМ в том виде, в каком он сейчас есть, действительно обладает какой-то громоздкостью, которая в большИх проектах может быть и оправдана. Но его основная идея - делать блоки независимыми, очень правильная. И уже сам убедился в этом. Очень сокращает время разработки\доработки новых страниц и элементов в уже существующих страницах.

Например есть какой-либо портал, в котором основные блоки выстроены в определенную структуру. В какой-то момент стало необходимо поменять три блока местами, а два вообще убрать и перенести на другую страницу портала, в которой имеется уже своя структура. Тут-то и проявляются все прелести независимости, когда берешь уже "готовый блок" и переносишь куда надо. При этом у тебя не валится верстка, не скачут шрифты и вообще нет никаких сюрпризов.

Сам я почти перестал использовать селекторы по типу и селекторы потомков в проектах. А если где и применяю, то только для стилизации "конечных" элементов блока, т.е. к тем элементам, что в БЭМ называется модификатором.

s0rr0w · October 20, 2011

У меня другой подход. Он чем-то похож на смесь ООП и unix-way.

Хоть и проектов у нас уже куча, но в css мы лазим только для того, чтобы оттуда что-то выкинуть, и очень редко - чтобы добавить. Это для меня явный признак успешности подхода.

Быколай · October 20, 2011

У меня другой подход. Он чем-то похож на смесь ООП и unix-way.
Хоть и проектов у нас уже куча, но в css мы лазим только для того, чтобы оттуда что-то выкинуть, и очень редко - чтобы добавить. Это для меня явный признак успешности подхода.

s0rr0w, а можно поподробней про ваш подход?

mishka, а я спискозадрот оказывается. ваш пример - ещё просто семечки :lol:

Про БЭМ так и не вкурил: это штука как-то автоматизирует процесс или всего лишь декларирует свои правила хорошего тона на основе идеологии независимости оформления элемента от контекста?

rediskavet · October 20, 2011

s0rr0w, присоединяюсь к просьбе Быколая, если можно поподробнее описать подход. Если можно с примерами кода.

Great Rash · October 20, 2011

NeoMurderer и ceil100 ваши высказывания это и есть бред "Не нравится, потому что громоздко", "километровые названия это бред" :facepalmxd:

Сам давно поглядываю в сторону БЭМ, но вот есть такой вопрос: у меня по специфике работы надо делать сайты максимально быстро, насколько увеличится время изначальной верстки? Если первоначальная концепция сайта меняется, скажем, до 3 раз в неделю, всего сайт может меняться от 2-3 до 10 раз, начиная с мелких изменений, заканчивая 80% переделки сайта, насколько легко мне будет менять структуру при таком подходе?

Даешь конкретные примеры!

Shift-Web · October 20, 2011

со временем я тоже стал думать о чем-то типа БЭМ. Даже на маленьких сайтах появилась привычка давать такие классы, с приставкой по их родителю. Если это логотип в хедере, то он у меня ".h-logo", или меню: ".h-nav", меню в сайдбаре ".s-nav". Я чувствовал необходимость такого подхода, но незнал как это сделать лучше. Когда узнал про БЭМ, мне эта идея очень понравилась. Насчет дилетанства в наименовании классов - бред. Такое мог сказать человек который только и делает маленькую страничку с css до 1000 строк, в таком формате:
div {
    width: 500px;
    margin: ...;
    padding: ...;
}
А когда с талкиваешся с тем что нужно проапдейтить проект, а в нем все сделанно полагаясь на каскадность, как говорит предыдущий автор и ты видишь такой код:
<form action="#">
    <fieldset>
        <div class="hold-text">
            <div><input type="text" /></div>
        </div>
    </fieldset>
</form>

.hold-text {
    width: ...;
    background: ...;
    .....
}
.hold-text div {
    padding: ...;
    background: ...;
    .....
}
.hold-text input {
    ...
}
И тут нужно рядом с инпутом всунуть еще блок с непростой структурой, у него внутри еще пара блоков будет то тогда приходится писать:
.hold-text .message {
    padding: auto;
    float: none;
    margin: auto;
    ....
}
.hold-text .message .m-frame {
    padding: auto;
    float: none;
    margin: auto;
    ....
}
Этот минимализм оправдан разве что в примерах, когда нужно кому-то показать как что работает, поэтому быстро набросал и показал. Но к сожалению многие это примут за чистую монету, и сами тоже начинают страдать минимализмом.
Вот пример спискозадротов:
<div class="gallery">
    <ul>
        <li><img src="" alt=""/></li>
        <li><img src="" alt=""/></li>
        <li><img src="" alt=""/></li>
    </ul>
    <ul class="switcher">
        <li><a href="#"></a></li>
        <li><a href="#"></a></li>
        <li><a href="#"></a></li>
    </ul>
</div>

.gallery ul {
    padding: 0;
    margin: 0;
    list-style: none;
    width: ;
    height: ;
    overflow: hidden;
    position: relative;
}
.gallery li { /* тут я немного сократил, обычно пишут .gallery ul li */
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
}
.gallery a { /* Это какая-то кнопочка в галлереи. тут я немного сократил, обычно пишут .gallery ul li a */
    position: absolute;
    top: 50px;
    left: 50px;
    width: 100px;
    height: 30px;
    background: url(image.png);
}
.gallery .switcher {
    width: auto;
    height: auto;
}
.gallery .switcher li {
    position: static;
    float: left;
}
.gallery .switcher a {
    position: static;
    width: ..;
    height: ..;
    background: ..;
}
А теперь представьте что в галлее не просто картинки будут, а там еще и описание полноценное появится, и внутрь ее придется всунуть простой маркированный список.
Это то с чем я часто сталкиваюсь.
А вот задай классы изначально элементам, да задай им стили через эти классы, а если еще и классы не от фанаря а логично будут проставлены(а в БЭМ так и есть), сделай лучше не себе в данный момент, а тем кто потом будет поддерживать твой код, возможно даже это ты будешь.
БЭМ - это не больная фантазия, это логичный результат многих часов работы.

Эти вопросы конечно можно предусмотреть, но, по идее, вся структура заранее известна. Что помешает сделать так: .gallery ul.class {} или обратиться через id(#gallery_1 .spisok1 {}), подняв на уровень выше комплексные правила для совпадений? Наглядный пример уникализации. В данном случае никаких особых трудностей не возникает.

Всё таки мне кажется дело не в БЭМ, а в понимании того, как это просиходит. Ибо даже навешав кучу уникальных префиксов и уникализировав всё в усмерть, можно такой хрени напороть, что потом одними оверрайдами вылезет тоже самое.

Что можно вынести в общие? Какие то чисто масштабные и пространственные параметры и т.д., а уникализировать на уровне чисто оформления(но это тоже очень по месту, есть куча фиговых примеров, когда такой подход лишает уникальности все проекты построенные по этому принципу.). Имхо ...

У меня другой подход. Он чем-то похож на смесь ООП и unix-way.
Хоть и проектов у нас уже куча, но в css мы лазим только для того, чтобы оттуда что-то выкинуть, и очень редко - чтобы добавить. Это для меня явный признак успешности подхода.

Если ваши проекты не похожи как яйца, то наверное да. Это можно назвать успешным.

Edited October 20, 2011 by Shift-Web

s0rr0w · October 20, 2011

Я особо не задумывался над тем, как его формализировать, но попробую рассказать.

Из чего состоит страница? Из нескольких логических объектов: основная навигация, шапка страницы, информационные блоки, сайдбары, фильтры, и так далее.

Для уникальных элементов, которые никогда не повторяются, можно применять уникальные "оддноразовые" классы (никогда не использую id для задания стилей). Тут можно и сложные селекторы применять, редко когда это будет меняться.

Для остальных элементов создаем логическую структуру. Например, из чего состоит список новостей? Из набора ссылок. Из чего состоит список статей? Из набора ссылок. Итак, у нас есть два блока, которые имеют одинаковую логическую структуру. Теперь строим следующую модель

<linkList>
 <linkItem>
  <url />
 </linkItem>
 <linkItem />
 ...
</linkList>

Она легко применима как к новостям, так и к списку статей. Но, у новостей, например, есть дополнительные элементы как картинка и дата публикации, а у статей есть автор.

Для этого создаем дополнительные логические структуры-модификаторы к нашей базовой модели

<linkList xmlns:news>
 <linkItem>
  <url />
  <news:image>
    <news:url>
  </news:image>
  <news:datetime>
    <news:date />
    <news:time />
  </news:datetime>
 </linkItem>
 <linkItem />
 ...
</linkList>

<linkList xmlns:articles>
 <linkItem>
  <url />
  <articles:author />
 </linkItem>
 <linkItem />
 ...
</linkList>

А теперь переведем все на html/css

<ul class="linkList news">
  <li>
    <span class="datetime">12.12.2012</span>
    <span class="image"><img src="img.png" alt=""></span>
    <a href="#">Новость</a>
  </li>
</ul>

linkItem мы не используем, так как он одинаковый для всех моделей.

Теперь несколько приемов по работе с оформлением. Я использую схему block->box для базовой модели оформления, в которой block отвечает за внешнее поведение блока относительно других блоков, а box отвечает за поведение содержимого.

Например:


<div class="metaBlock">
  <div class="metaBox">
   ...
  </div>
</div>

.metaBlock { margin: 10px 0px; }
.metaBox { padding: 10px; }

Иногда модель расширяется до более сложных вариантов по типу container->block->box->contentbox. Но в целом, все стараемся приводить к одинаковым вариантам.

Если нужно управлять поведением блока в потоке, например, сделать его float: left, то я применяю модификатор .lFloat к .metaBlock.

В общем можно описать работу над css в таком ключе: создал логическую структуру элементов, сделал модифицирующие структуры. Для более точного поведения использую модификаторы.

psywalker · October 20, 2011

каскадные таблицы на то и каскадные, чтобы использовать всю их силуа множить количество классов до бесконечности, да еще давать им километровые названия это бредэто подход дилетанта, который не понимает вложенности, что куда определяется и как этим пользоватьсяБЭМ это подход программиста, который не понимает и не хочет понять что такое CSS, зато он знает ООП и делает себе костыль из него,а потом говорит, что без этого костыля ходить не возможно.не знаю насколько большим должен быть проект, чтобы использовать БЭМ, но достаточно посмотреть на CSS БЭМ-сайта, чтобы понять, что это бредто что можно вместить в тридцать строк при правильном коде там растянуто на триста с лишним, с классами по три километра длинойс таким кодом нагрузка не только не уменьшится, она возрастет еще больше, а поддерживать такой код, это же с ума сойдешь когда сайт еще в пару раз увеличится

Вот это мнение человека, который совершенно не понимает, о чём идёт речь.

БЭМ - это не просто засорение кода ненужными классами и я считаю, что его использовать можно и нужно, но не быть фанатом и смотреть на ситуацию.

Вот пример.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Документ без названия</title>
<style type="text/css">
	.nav {}
		.nav > li {}
				.nav > li > a {}

		.nav__dropdown {}
			.nav__dropdown > li {}
				.nav__dropdown > li > a {}
</style>
</head>

<body>

	<ul class="nav">
		<li> <a href="#">1</a>
			<ul class="nav__dropdown">
				<li>
					<a href="#">Выпадающий пункт</a>
				</li>
			</ul>			
		</li>
		<li> <a href="#">2</a>
			<ul class="nav__dropdown">
				<li>
					<a href="#">Выпадающий пункт</a>
				</li>
			</ul>			
		</li>
	</ul>

</body>
</html>

Я показал пример, для обычных проектов, простых (не крупных порталов). Т.е. если бы я использовал отчасти БЭМ на простых хомяках, я бы делал так.

Объясняю суть.

Тут, на дочерних селекторах, мы теряем в скорости, но учитывая, что это обычный хомяк, разницы мы не замечаем.

	.nav {}
		.nav > li {}
				.nav > li > a {}

Плюсы:

1) Мы избавляемся от "лишних" классов, которые вешаются на всё живое, например на те же li

2) Мы не теряем удобочитаемость нашего кода, т.е. код с таким подходом остаётся вполне читаемый и понятный.

3) Мы так же можем смело сказать, что наш блок - независимый и что все его обращения к элементам внутри происходят только на его уровне, не затрагивая, например элементы такого же типа внутри него. Опять же, проблема независимости решается тут за счёт дочерних селекторов.

4) Мы так же легко можем убирать, или наоборот вводить вложенные элементы внутрь, они так же вполне себе самостоятельны за счёт своих классов

			<ul class="nav__dropdown">
				<li>
					<a href="#">Выпадающий пункт</a>
				</li>
			</ul>

		.nav__dropdown {}
			.nav__dropdown > li {}
				.nav__dropdown > li > a {}

Если внутри нужны какие-то отдельные элементы, то мы вешаем на них класс, и это лишит нас последних проблем. Таким образом на выходе мы имеем вполне себе удобочитаемый, управляемый и самое главное независимый код.

Я к тому, что не стоит брать БЭМ за догму, не стоит не видеть ничего вокруг и использовать эту технику в полном объёме в своих проектах, особенно в малометражных, если этого не требует ситуация.

Можно и "даже" нужно использовать его правильно и исходить от задачи и объёма сайта. На проектах, которые ты один раз сверстал и забыл или раз сверстал и возвращаешься к нему редко, вполне подойдёт мой подход.

Есть возражения?

Shift-Web · October 20, 2011

Не так задротно, но логика весьма хороша: http://twitter.github.com/bootstrap/

rash · October 20, 2011

каскадные таблицы на то и каскадные, чтобы использовать всю их силу

Именно из-за этого желания использовать «всю силу» CSS и получается смесь каши и спагетти в стилевых файлах, особенно если их долго поддерживают, и особенно если их поддреживают разные люди.

Мне больше нравится (и регулярно убеждаюсь в правильности) фраза «мы не должны делать глупости в CSS только потому, что технология CSS позволяет нам это».

Возможности каскадирования, например, использовать можно, но не потому, что CSS так умеет, а потому, что иногда это бывает уместно.

а множить количество классов до бесконечности, да еще давать им километровые названия это бред
это подход дилетанта, который не понимает вложенности, что куда определяется и как этим пользоваться

Ой-ой-ой Километровые названия мне тоже не нравились поначалу, однако надо признать, что ничего лучше я так и не смог придумать, хотя был полон энтузиазма поначалу. Просто это в действительности хороший, наглядный подход, длинные имена отталкивают непривычностью, но это, как легко догадаться, дело привычки. Да и минимизировать их на продакшене никто не запрещает, просто это не всегда нужно.

Расскажите, как же правильно понять вложенность, что куда определяется и как этим пользоваться? Чего я не понимаю? Я действительно очень хочу разобраться, в чем мой практический опыт ошибочен?

И да, если самодокументирующийся код — это признак подхода дилетанта, то всем бы быть такими дилетантами

Хоть и проектов у нас уже куча, но в css мы лазим только для того, чтобы оттуда что-то выкинуть, и очень редко - чтобы добавить. Это для меня явный признак успешности подхода.

Это действительно признак успешности подхода, но он ничего не говорит об универсальности подхода. По крайней мере он хорошо подходит к вашим проектам с учетом их особенностей, это действительно успех. Ну и есть в этих подходах что-то отдаленно-общее.

БЭМ это подход программиста, который не понимает и не хочет понять что такое CSS, зато он знает ООП и делает себе костыль из него,
а потом говорит, что без этого костыля ходить не возможно.

И вновь я попрошу вас объяснить, что такое CSS, и как его постичь, чтобы не было желания сделать из него что-то приличное

не знаю насколько большим должен быть проект, чтобы использовать БЭМ, но достаточно посмотреть на CSS БЭМ-сайта, чтобы понять, что это бред
то что можно вместить в тридцать строк при правильном коде там растянуто на триста с лишним, с классами по три километра длиной
с таким кодом нагрузка не только не уменьшится, она возрастет еще больше, а поддерживать такой код, это же с ума сойдешь когда сайт еще в пару раз увеличится

Насколько большим? Ну посмотрите на проекты Яндекса (не на каждый сервис в отдельности, а на портал в целом), уже мейл.ру начинает использовать, насколько я знаю, хедхантер использовал (не знаю, как сейчас).

Нагрузка на что? На серверсайд? Сгенерировать шаблоном длинный класс не тжелее, чем короткий. На канал? Gzip сводит разницу к минимуму. На клиента? Нагрузка только уменьшается, за счет неиспользования неэффективных селекторов.

Тем более, что если поддержка IE6 не нужна принципиально, именование классов можно изменить, использовать селекторы со множественными классами и радоваться. Вот только в таким случае селекторы снова изрядно потеряют в эффективности, а именно производительность браузеров послужила причиной того, что о подобном подходе, вообoе, задумались.

Поддерживать такой код легче Никто же не редактирует стили и разметку в виде тех простыней, которые вы видите в браузере. Мне приходилось поддерживать как верстку с «классическим» подходом (причем, свою), так и верстку с БЭМ-подходом (причем не только свою). БЭМ поддерживается легче.

БЭМ - это не просто засорение кода ненужными классами и я считаю, что его использовать можно и нужно, но не быть фанатом и смотреть на ситуацию.

Пожалуй, для небольшого проекта, который будет поддерживать ограниченное количеств людей, я бы тоже основывался на БЭМ-подходе, но позволял себе отступать от него для придания коду большей элегантности и создания каких-нибудь приятных фишек (которые потребуют экзотических селекторов, глобальных модификаторов или чего-нибудь еще, не особо соответствующего идеологии и уменьшающего производительность верстки).

psywalker · October 20, 2011

rash,

БЭМ - это не просто засорение кода ненужными классами и я считаю, что его использовать можно и нужно, но не быть фанатом и смотреть на ситуацию.
Пожалуй, для небольшого проекта, который будет поддерживать ограниченное количеств людей, я бы тоже основывался на БЭМ-подходе, но позволял себе отступать от него для придания коду большей элегантности и создания каких-нибудь приятных фишек (которые потребуют экзотических селекторов, глобальных модификаторов или чего-нибудь еще, не особо соответствующего идеологии и уменьшающего производительность верстки).

Ну а как ты думаешь, вот этот пример соответствует тому, о чём ты говоришь http://forum.htmlbook.ru/index.php?showtopic=30108&view=findpost&p=229248 ? Т.е. для простых сайтов он подходит или всё таки нет? Чтобы ты убрал/добавил?

rash · October 20, 2011

БЭМ-у не соответствует, но я бы делал так на небольших проектах и не парился

С одной стороны привязка к структуре (селектор ребенка «>») не очень хорошо, но не сильно просадит производительность, очистит разметку от громоздких классов, и если поддерживать будет один и тот же человек — не сильно затруднит поддержку. Так что ОК, на мой субъективный взгляд.

s0rr0w · October 20, 2011

С одной стороны привязка к структуре (селектор ребенка «>») не очень хорошо

В CSS не бывает хорошо или плохо. Оно было придумано и оно работает, а хорошо или плохо - чистейшей воды субъективизм.

rash · October 20, 2011

С одной стороны привязка к структуре (селектор ребенка «>») не очень хорошо
В CSS не бывает хорошо или плохо. Оно было придумано и оно работает, а хорошо или плохо - чистейшей воды субъективизм.

Плохо дл поддержки. Если работает и не трогать — любое работающее решение будет по крайней мере приемлемым.

Разумеется, если нет дополнительных ограничений (экономия каждого байта, особенности шаблонизатора и т.п.)

В CSS бывает хорошо и плохо, но очень редко на это действительно нужно обращать внимание. Поэтому я бы при таком коде тоже не парился

s0rr0w · October 20, 2011

Плохо дл поддержки.

Это уже мера оценки.

Все имеет свою стоимость, кому-то нужно как можно скорее сделать работу и забыть, кому-то нужно сделать так, чтобы завтра, когда наступит время изменений, все не развалилось. Кому-то нужно, чтобы стоимость изменений была минимальная.

Sign In

БЭМ

Recommended Posts

Link to comment

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

Nanto

Nanto

Nanto

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Обсуждения

Important Information